When Autodesk released the DirectShape API a few years ago - I thought it was fantastic. Finally a way to make random geometry that could live on within Revit - instead of just the elements that the API allows us to make in the way the API allows us to make.

We used this for an interesting effect in our own Scan to BIM product - a mechanism for recording irregular shapes as Revit geometry. What is also interesting - besides the creation of geometry, you can use the API to assign these objects to almost any desired category. Think about it for a moment - you can make any piece of geometry and declare that it is a wall, a room, a staircase, etc.

This felt incredibly cool but also incredibly dangerous for me, from a BIM perspective. And although assigning some features of a wall comes from assigning the wall category - it is not a real wall element and there are many limitations.

This week

This week I experienced the downside of this approach for the first time. A customer used one of our other tools on one of his models and it threw a weird exception in our app. We looked through the logbooks and based on what we saw it seemed like a problem with model damage. We had a method that retrieved all phases with spaces from that stage - and one of the rooms apparently had a phase that was not actually a phase in this model. How could this happen? maybe corruption? maybe a problem with cutting and pasting between models?

We started working on a solution from that angle, but a day later the customer could share the model with us. When we executed it via the debugger, we saw in which room the phase was associated: -1 (nothing). This did not seem possible in our experience. Then we looked closer - the element in question was not actually a room - it was an element of DirectShape. How did that happen for goodness?!?

The real problem in the code, that we had written this kind of thing a thousand times in the last 6 or 7 years (since the FilteredElementCollector was invented), looked something like this:

FilteredElementCollector coll = new FilteredElementCollector (myDoc);

IList elements = coll.OfCategory (BuiltInCategory.OST_Rooms) .ToElements ();

Historically, if everything you wanted were the elements that were rooms, this was all you needed.

That said, an API developer had created an add-on that created a DirectShape box and assigned it to the Room category.

So if we continue, as API developers we can no longer rely on the category (or even Category / IsElementNotElementType) as reliable .NET-type indicators in the Revit API.

Our quick solution to this specific problem was:

IListic elements =

coll.OfCategory (BuiltInCategory.OST_Rooms) .OfClass (typeof (SpatialElement)) .ToList ();

This ignores all DirectShape elements that were displayed as rooms. We quickly found other places (in other ways) where we had made the bad assumption and we had casting errors such as:

I List spaces =

coll.OfCategory (BuiltInCategory.OST_Rooms) .Cast (). ToList ();

The Direct Shape elements were not released in Cast at runtime.

Even if this is resolved, these problems will undoubtedly become confusing. I believe that in many cases the Direct Shape elements can still be planned as their assigned category, so that our customers will think they have N-chambers in the model, while in fact only a few of them are 'real' rooms.

I am still working on it, but I think you should always have an "Of Class (type of MyDesiredClass)" on the collector. If you do not, you can get things that you do not expect.

All in all it is not so bad to deal with it, if you know it. The key is that it is a loophole that other app developers can open, and each of us who makes software that you do not know which other add-on has been used, must ensure that we are doubly careful with our assumptions. And I'm not looking forward to digging back through all the code I've ever written and still support to find all the bad assumptions I've made.